Telephones no longer just transmit and receive telephone calls. Devices including cellular telephones, PDAs, laptop computers, and so on, collectively referred to as user equipment (UE), may transmit and receive telephone calls, may transmit and receive text messages, may participate in video-conferencing, may participate in multi-player gaming, may share content, and so on. These types of activities may be referred to collectively as multimedia services. In some cases these multimedia services may be provided over the Internet using the Internet Protocol (IP).
An IP Multimedia Core Network Subsystem (IMS) includes core network (CN) elements for providing IP multimedia services. These IP multimedia services may include telephony (e.g., Voice over IP (VoIP)), push to talk over cellular (PoC), text messaging, and so on. Within various services, other sub-services may be provided. For example, in the telephony service, sub-services including call forwarding, call waiting, voice mail, multi-party calling, and so on, may be provided. Conventionally, each of these services and/or sub-services may have been provided by a stand-alone electronic system, computer, and/or computer system. Various IMS switches may be configured with information, for example, on a per-session basis to facilitate connecting users to services and to facilitate charging users for services.
IMS defines how requests for service are routed to an Application Server (AS) that can provide the service. IMS also may also define which protocols are supported in a communication network, how a user is charged, and so on. A user may access services via a dynamically associated, service-independent, standardized access point referred to as a call session control function (CSCF). A CSCF may be allocated dynamically to a user at log-on or when a request addressed to the user is received. Since an IMS may include multiple CSCFs, a decision may be made on which CSCF to allocate to a user. This decision may be made, at least in part, by comparing server capabilities available in a CSCF to server capabilities required and/or desired by a user. To facilitate interacting with a user, a CSCF may acquire data that is more permanently stored in a Home Subscriber Server (HSS) (e.g., user data, charging information). Once authenticated through an IMS service, the user may access other IMS services for which the user is authorized. Authentication may be handled by the CSCF as the user signs on.
Services are not provided in a vacuum. For example, user demand may provide a rationale for providing services. Thus, not all services are provided free of charge. Organizations with an IMS based communication network may store data concerning their network. These organizations may store data not only about their network (e.g., configuration) but also about the users (e.g., subscribers) who use the network, devices (e.g., CSCF) that participate in providing services, charging information, billing information, and so on. Conventionally, IMS networks may have used a large database that stored a record for each subscriber. The database may have stored information including public and private user identities, services subscribed to, charges incurred, a subscriber's home network, a service provided by an AS, a CSCF available to handle communications, CSCF capabilities, and so on.
Since a CSCF may participate in communications, since communications may be billed for, and since a user may communicate, information about a CSCF or charging may have been stored in subscriber records. However, this may create provisioning, updating, maintenance, and other issues for database systems administrators and network administrators. By way of illustration, consider a business that manages a network having one million subscribers that use different services. Further consider that 100,000 of these subscribers are using the network at any given time. In this situation 100,000 users may be using a set of CSCFs having different capabilities and may be taking actions that incur charges. If information concerning a CSCF capability changes, then the system administrator may need to locate relevant CSCFs and update each of them. Similarly, if charging information (e.g., charging function, collection function) changes, then the system administrator may need to locate records associated with all the affected users and then change each of these records.
Additionally, adding and/or defining a user may create issues. For example, every user that is added or defined in the database may force the administrator to have to re-provision and define CSCF and/or billing information for the user. This creates many opportunities for errors as each record is individually provisioned with CSCF and/or billing data.
However, the issues do not stop with database record maintenance. As described above, messages may be handled by a CSCF. Handling the message may include acquiring user information and distributing it to various switches in a communication network. For example, a logical CSCF, which may include several physical components, may acquire user information including capabilities information and charging information. Now if the charging information changes, not only does each user record having the charging information have to change, but so too does each CSCF component having the charging information. In a large network this switch updating may be burdensome.